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(57) Abstract 

A storage unit made of a flash array (58) and a Universal Serial Bus (USB) controller (56) is implemented to be compatible with 
the USB specification. The unit (46) includes memory modules (58) which can accept write commands and read commands from a host 
(44). and are erasable and non-volatile, referred to as flash modules (58). The USB/flash controller (56) is configured to provide USB 
functionality and compatibility along with common flash operations such as programming, reading, and erasing the flash modules (58). 
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ARCfflTECnjRE FOR A UNIVERSAL SERIAL BUS-BASED 
PC FLASH DISK 

Field and Background of the Invention 

5 The present invention is related to semiconductor memory devices, and in 

particular to erasable and prograiximable nonvolatile memory modules which are 
connected to a host platform using the USB PC Bus. 

Erasable and programmable non-volatile memory modules, hereinafter 
referred to as flash memory or flash devices, are known in the art for storage of 

10 information. Flash devices include electrically erasable and progranmiable read-only 
. memories (EEPROMs) made of flash-type, floating-gate transistors and are non- 
volatile memories similar in functionality and perfomiance to EPROM memories, 
with an additional functionality that allows an in-circuit, programmable, operation to 
erase pages of the memory. One example of an implementation of such a flash device 

15 is given in U.S. Patent No. 5,799,168, incorporated by reference as if fiiUy set forth 
herein. 

Flash devices have the advantage of being relatively inexpensive and requiring 
relatively little power as compared to traditional magnetic storage disks. However, in 
a flash device, it is not practical to rewrite a previously written area of the memory 

20 without a preceding page erase of the area. This limitation of flash devices causes 
them to be incompatible with typical existing operating system programs, since data 
cannot be written to an area of memory withm the flash device in which data has 
previously been written, unless the area is first erased. A software management 
system, such as that disclosed in U.S. Patent No. 5,404,485, filed on March 5, 1993, 

25 which is incorporated as if fully set forth herein, is required to manage these functions 
of the. flash memory device. 

Currently, these flash memory devices have a second limitation, which is that 
they must be either attached statically to the host platform, or attached and detached 
dynamically using the PCMCIA [Personal Computer Memory Card International 

30 Association] interface. Both implementations have drawbacks, including difficulty of 
use and high cost. 

A more useful implementation would follow the USB standard, as described in 
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the USB Specification Version 1.1 which is incorporated as if fully set forth herein. 
The USB standard offers a smaller form factor and greater ease of use for the end user, 
while lowering the cost of the implementation. This standard is specified to be an 
industry-wide standard promoted by companies such as Compaq Coniputer 

5 Corporation, Microsoft , IBM and Intel to serve as an extension to the PC architecture 
with a focus on Computer Telephony Integration (CTI), the consumer, and 
productivity applications. 

The criteria which were applied to define the architecture for the USB standard 
include the ease of PC (personal computer) peripheral expansion, low cost, support of 

10 transfer rates up to 12Mb/second and full support for real-time data, voice, audio, and 
. compressed video. This standard also offers protocol flexibility for mixed-mode 
isochronous data transfers and asynchronous messaging, integration in commodity 
device technology and provision of a standard interface for rapid integration into any 
given host product. In addition, the USB standard represents a single model for 

15 cabling and attaching coimectors, such that all of the details of the electrical functions, 
including bus terminations, are isolated from the end user. Through the standard, the 
peripheral devices are self-identifying, and support automatic mapping of functions to 
a driver. Furthermore, the standard enables all peripheral devices to be dynamically 
attachable and re-configurable. 

20 A system constructed according to the USB standard is described by three 

separate, defined areas: USB interconnection, USB devices and the USB host 
platform. The USB interconnection is the manner in which USB devices are 
connected to, and communicate with, the host platform. The associated functions and 
components include the bus topology, which is the cormection model between USB 

25 devices and the host platform. 

The USB physical interconnection has a tiered star topology. A hub is at the 
center of each star. Each wire segment is a point-to-point connection between the host 
platform and a hub or function, or a hub connected to another hub or function. 

In terms of a capability stack, the USB tasks which are performed at each layer 

30 in the system include a data flow model and a schedule. A data flow model is the 
maimer in which data moves in the system over the USB between data producers and 
data consumers. A schedule determines access to the interconnection, which is 
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shared. Such scheduling enables isochronous data transfers to be supported and 
eliminates arbitration overhead. 

The USB itself is a polled bus. The host controller on the host platform 
initiates all data transfers. All bus transactions involve the transmission of up to three 

5 packets. Each transaction begins when the host controller, on a scheduled basis, sends 
a USB packet describing the type and direction of transaction, the USB device 
address, and endpoint number. This packet is referred to as the "token packet." The 
USB device, to which the packet is addressed, selects itself by decoding the 
appropriate address fields. In a given transaction, data is transferred either from the 

10 host platform to a device or from a device to the host platform. The direction of data 
transfer is specified in the token packet. The source of the transaction then sends a 
data packet or indicates that the source has no data to transfer. The destination, in 
general, responds with a handshake packet indicating whether the transfer was 
successful. 

15 xhe USB data transfer model between a source and destination on the host 

platform and an endpoint on a device is referred to as a "pipe". There are two types of 
pipes: stream and message. Stream data has no USB-defined structure, while message 
data does. Additionally, pipes have associations of data bandwidth, transfer service 
type, and endpoint characteristics like directionality and buffer sizes. Most pipes come 

20 into existence when a USB device is configured. One message pipe, the default 

control pipe, always exists once a device is powered, in order to provide access to the 
configuration, status, and control information for the device. 

The transaction schedule for the USB standard permits flow control for some 
stream pipes. At the hardware level, this prevents situations in which buffers 

25 experience underrun or overrun, by using a NAK handshake to throttle the data rate. 
With the NAK handshake, a transaction is retried when bus time is available. The 
flow control mechanism permits the construction of flexible schedules which 
accommodate concurrent servicing of a heterogeneous mix of stream pipes. Thus, 
multiple stream pipes can be serviced at different intervals with packets of different 

30 sizes. 

The USB standard, as described, has three main types of packets, including 
token packets, data packets and handshake packets. An example of each type of 
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packet is shown in background art Figures 1-3. Background art Figure 4 shows an 
exemplary USB abstract device. 

A token packet 1 0, as shown in background art Figure 1 , features a PID 
(packet identification) field 12. specifying one of three packet types: IN, OUT, or 
5 SETUP. If PID field 12 specifies the IN packet type, the data transaction is defined 
firom a fimction to the host platform. If PID field 12 specifies the OUT or SETUP 
packet type, the data transaction is defined fi-om the host platform to a fiinction. 

An ADDR field 14 specifies the address, while an ENDP field 1 6 specifies the 
endpoint for token packet 10. For OUT and SETUP transactions, in which PID field 

10 12 specifies that token packet 10 is an OUT packet type or a SETUP packet type, 
ADDR field 14 and ENDP field 16 uniquely identify the endpoint for receiving the 
subsequent data packet, shown in Figure 2, which follows after token packet 10. For 
IN transactions, in which PID field 12 specifies that token packet 10 is an IN packet 
type, ADDR field 14 and ENDP field 16 uniquely identify which endpoint stransmit a 

15 data packet. A CRC5 field 18 contains the checksum, for determining that token 
packet 10 has been received without conruption. Only host platform can issue token 
packets 10, such that token packets 10 provide control over transmission of the 
subsequent data packets. 

As shown in background art Figure 2, a background art USB data packet 20 

20 also features a PID (packet identification) field 22 for identifying the type of data 

packet. Data packet 20 also features a data field 24 for optionally containing data, and 
a CRC field 26 for containing the checksum as previously described. 

Background art Figure 3 shows a background art USB handshake packet 28, 
which features only a PID (packet identification) field 30. Handshake packets 28 are 

25 used to report the status of a data transaction and can return values indicating 

successful reception of data, command acceptance or rejection, flow control, and halt 
conditions. Only transaction types which support flow control can return handshake 
packets 28. Handshake packets 28 are always returned in the handshake phase of a 
transaction and may be returned, instead of data packets 20, in the data phase of a 

30 transaction. 

These three different types of packets are exchanged during various phases of 
the transaction which includes a USB device. A schematic block diagram of the 
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functional blocks in a typical USB device 32 is shown in Figure 4 for an abstract 
background art USB device. USB device 32 typically includes a USB electrical 
interface 34, featuring a cable and a connector, which is a physical interface for 
receiving and transmitting electrical signals which are compatible with the USB 
5 specification as previously described. The signals are then passed to a logical 
interface 36, which includes one or more buffers, the device address decoder for 
decoding the address of the source device for the signals, and a SYNC field 
synchronizer for synchronizing the signals. Information and structures required for 
management of USB abstract device 32 as a USB device are stored in a USB class 

10 control and enumeration engine 38. A fimction and device engine 40, also temied the 
"application", controls and manages the specific functions and properties of USB 
abstract device 32. In addition, function and device engine 40 also consumes and 
produces most of the data over the USB bus. 

The USB specification does not define the relationship between different 

15 entities in USB abstract device 32, however. Rather, the USB specification describes 
only the requirements for the packets, and for the electrical and physical connection 
between USB abstract device 32 and the bus. Therefore the connections and 
relationships shown in background art Figure 4 are only one example of an 
implementation which fulfills the requirements of the USB specification. Thus, any 

20 specific device for fiilfilling the USB specification must have a specifically defined 
and described architecture. 

Unfortunately, no such architecture exists for a flash memory device 
containing one or more flash memory modules, which would enable the flash memory 
device to connect to a bus defmed according to the USB specification and thereby to 

25 fonn part of a USB system on a host platform. For example, U.S. Patent No. 

5,799,168 does not teach or suggest such an implementation for the flash device. As 
mentioned previously, such an architecture would be particularly useful for a number 
of reasons, incliiding low cost, ease of use and transparency to the end user. 

There is thus a need for, and it would be useful to have, an architecture for 

30 defining and describing a flash memory device which is compatible with a USB 
system and which follows the USB specification, such that the flash memory device 
could sit on a USB-defined bus and communicate with the host platfomi through this 
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bus. 

Brief Description of the Drawings 

FIG. 1 is a schematic block diagram of a background art USB token packet 
5 structure; 

FIG. 2 is a schematic block diagram of a background ait USB data packet 
structure; 

FIG. 3 is a schematic block diagram of a background art USB handshake data 
packet structure; 

10 FIG. 4 is a schematic block diagram of an exemplary background art USB 

device; 

' FIG. 5 is a schematic block diagram of a system with a flash USB device 
functionality according to the present invention; 

FIG. 6 is a schematic block diagram of the USB Flash disk; 
15 FIG. 7 is a schematic block diagram of a flash identification request packet; 

FIG. 8 is a schematic block diagram of a flash identification status packet; 

FIG. 9 is a schematic block diagram of a flash write request packet; 

FIG. 10 is a schematic block diagram of a flash write status packet; 

FIG. 1 1 is a schematic block diagram of a flash read request packet; 
20 FIG. 12 is a schematic block diagram of a flash read status packet; 

FIG. 13 is a schematic block diagram of a flash erase request packet; and 

FIG. 14 is a schematic block diagram of a flash erase status packet. 

Summary of the Invention 

25 The present invention is of a flash memory device, containing one or more 

flash modules, in which the flash memory is mapped to the address space of an ASIC 
or a controller which has a USB-defmed electrical interface and a USB-defined logical 
interface. This controller/ASIC (hereinafter termed a "controller") supports the USB 
functionaUty according to the USB standard, thereby supporting enumeration onto the 

30 USB bus, as well as data reception and transmission over USB pipes to and firom USB 
endpoints. This controller also supports the functionality and control of the flash 
memory device, as well as the processing of command and data packets from the host 
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controller. The host controller uses one of several possible protocols, either standard 
or proprietary, to signal the next command to be performed to the USB flash 
controller. Thus, the entire device acts as a dynamically attachable/detachable non- 
volatile storage device for the host platform, 
5 According to the present invention, there is provided a USB flash memory 

device for connecting to a USB-defmed bus, the flash memory device comprismg: (a) 
at least one flash memory module for storing data; (b) a USB connector for 
connecting to the USD-defined bus and for sending packets on, and for receiving 
packets from, the USB-defined bus; and (c) a USB controller for controlling the at 

10 least one flash memory module and for controlling the USB connector according to at 
^ least one packet received from the USB-defined bus, such that data is written to and 
read from the at least one flash memory module. 

Hereinafter, the term "computer" includes, but is not limited to, persona! 
computers (PC) having an operating system such as DOS, Windows™, OS/2™ or 

15 Linux; Macintosh"^" computers; computers having JAVA'^m.qs as the operating 

system; and graphical workstations such as the computers of Sun Microsystems"^" and 
Silicon Graphics'^^, and other computers having some version of the UNIX operating 
system such as ADC^" or SOLARIS^" of Sun Microsystems'^; or any other known 
and available operating system, including operating systems such as Windows CE^" 

20 for embedded systems, including cellular telephones, handheld computational devices 
and palmtop computational devices, and any other computational device which can be 
connected to a network. Hereinafter, the term "Windows*^" includes but is not 
limited to Windows95'^, Windows 3.x™ in which "x" is an integer such as "1", 
Windows Nr*^*, Windo ws98'™, Windows CE™ and any upgraded versions of these 

25 operating systems by Microsoft Inc. (Seattle, Washington, USA). 

Detailed Description of the Invention 

The present invention is of a flash memory device, containing one or more 
flash modules, in which the flash memory is mapped to the address space of an ASIC 
30 or a controller which has a USB-defined electrical interface and a USB-defmed logical 
interface. This controller/ASIC (hereinafter tenned a "controller") supports the USB 
fiinctionality according to the USB standard, thereby supporting enumeration onto the 
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USB bus, as well as data reception and transmission over USB pipes to and from USB 
endpoints. This controller also supports the functionality and control of the flash 
memory dev, as well as the processing of command and data packets from the host 
controller. The host controller uses one of several possible protocols, either standard 
5 or proprietary, to signal the next command to be perfonned to the USB flash 

controller. Thus, the entire device acts as a dynamically attachable/detachable non- 
volatile storage device for the host platform. 

While the invention is susceptible to various modifications and can be 
implemented using many alternative forms, the embodiment is shown by way of 
10 example in the drawings and will be described in details in the following pages. It 
should be understood that one of ordinary skill in the art appreciates that the present 
invention could be implemented in various other ways. The intention is to cover all 
modifications and alternatives falling within the spirit of the current invention. 

The principles and operation of a USB flash device and system according to 
15 the present invention may be better understood with reference to the drawings and the 
accompanying description, it being understood that these drawings are given for 
illustrative purposes only and are not meant to be limiting. 

Referring now to the drawings. Figure 5 is a schematic block diagram of the 
main components of a flash memory device and system according to the present 
20 invention. A flash memory system 42 includes a host platform 44 as shown. Host 
platform 44 operates USB flash device 46 as a non-volatile storage space. 

Host platform 44 is connected to USB flash device 46 according to the present 
invention through a USB cable 48. Host platform 44 connects to USB cable 48 
through a USB host connector 50, while USB flash device 46 connects to USB cable 
25 48 through a USB flash device connector 52. Host platform 44 features a USB host 
controller 54 for controlling and managing all USB transfers on the USB bus. 

USB flash device 46 features a USB flash device controller 56 for controlling 
the other components of USB flash device 46 and for providing an interface for USB 
flash device 46 to the USB bus, USB flash device connector 52 and at least one flash 
30 memory module 58. Flash memory module 58 is preferably an array of flash memory 
modules 58 in which the data is stored. 

Whenever USB flash device 46 becomes connected to host platform 44, a 
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Standard USB enumeration process takes place. In this process host platform 44 
configures USB flash device 46 and the mode of communication with USB flash 
device 46. Although there are many different methods for configuring USB flash : 
device 46, for the purposes of clarity only and without intending to be Hmiting, the 
5 present invention is explained in greater detail below with regard to a method in 

which host platform 44 issues commands and requests to USB flash device 46 through 
one endpoint. Host platform 44 queries USB flash device 46 through the other 
endpoint for status changes, and receives related packets if any such packets are 
waiting to be received. 

10 Host platform 44 requests services from USB flash device 46 by sending 

request packets to USB host controller 54. USB host controller 54 transmits packets 
on USB cable 48. These requests are received by USB flash device controller 56 when 
USB flash device 46 is the device on the endpoint of the request. USB flash device 
controller 56 then performs various operations such as reading, vmting or erasing data 

15 from or to flash memory module(s) 58, or supporting basic USB functionality such as 
device enumeration and configuration. USB flash device controller 56 controls flash . 
memory module(s) 58 by using a control line 60 to control the power of flash memory 
module(s) 58, and also through various other signals such as chip enable, and read and 
write signals for example. Flash memory module(s) 58 are also connected to USB 

20 flash device controller 56 by an address/data bus 62. Address/data bus 62 transfers 
commands for performing read, write or erase commands on flash memory module(s) 
58, as well as the addresses and data for these commands as defined by the 
manufacturer of flash memory module(s) 58. 

In order for USB flash device 46 to notify host platform 44 on the result and 

25 status for different operations requested by host platform 44, USB flash device 46 
transmits status packets using the "status end point". According to this procedure, 
host platform 44 checks (polls) for status packets and USB flash device 46 returns 
either an empty packet if no packets for new status messages are present, or 
alternatively returns the status packet itself 

30 A more detailed structure of the functional components of USB flash device 

46 is shown in Figure 6. USB flash device 46 includes the physical and electrical 
interface defined for the USB standard, shown here as USB flash device connector 52 
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and a connector interface 64. USB flash device connector 52 receives the. electrical 
signals from USB cable 48 which carries electrical signals from host controller (not 
shown). These signals are then passed through connector interface 64. Every 
millisecond, a USB frame is earned on the USB-defmed bus, such that packets could 
5 be sent to USB flash device 46. 

Connector interface 64 then receives these packets through a first interface 
component, which is a combined physical and logical interface 66. A fimctional 
interface 68 is specifically designed to receive token packets as defined in the USB 
specification and as previously described with regard to Figure 1. These token packets 

10 are related only to particular functional aspects of USB flash device 46 which are 
required for the USB standard, and do not have any relation to particular application 
of USB flash device 46 as a flash disk according to the present invention. These token 
packets and their respective returned data packets enable USB host controller 54 (not 
shown) and host platform 44 (not shown) to identify USB flash device 46 and allocate 

15 resources for USB flash device 46 on the USB bus. Thus, fiinctional interface 68 only 
supports USB fiinctionality needed for the identification and registration of USB flash 
device 46 on the USB bus. 

USB flash device 46 also features an application packet extractor 70 which 
extracts the application data and commands from the USB application packets, such 

20 that application packet extractor 70 supports only application related packets. Next, 
any requests to USB flash device 46 by host platform 44 (not shown), in the form of 
read, write, identify and erase commands, are interpreted by an application command 
interpreter 72. For any commands which involve data or an address, such as read, 
write and erase commands, an address resolve module 74 translates the address from 

25 the logical address space to the physical address space. Host platform 44 (not shown) 
relates to a linear address space of logical addresses, while USB flash device 46 
contains at least one, and preferably a plurality of, flash modules 58, each of which 
has a physical address space. Thus, a translation must be performed between the 
logical address space of host platform 44 (not shown) and physical address space or 

30 spaces of USB flash device 46. There are many ways to implement such a translation 
which are suitable for the present invention. One example of a suitable 
implementation of an address translation method is described with regard to U.S. 
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Patent No. 5,404,485, previously incorporated by reference as if folly set forth herein, 
which teaches a method for managing a flash memory as a flash disk and which is 
suitable for operation with the present invention. 

A data handler 76 handles data related aspects of any received commands, and 
5 conveying the data through fonctional interface 68 to and from flash module(s) 58. 
. Optionally and preferably, data handler 76 performs any error correction and 
detection methods. Application command interpreter 72, data handler 76 and address 
resolve module 74 all operate with an underlymg Memory Technology Driver (MTD) 
78 to write, read or erase a particular flash module 58 and the desired address on that 
10 flash module 58. 

Host platform 44 checks for status changes in USB flash device 46 and reads 
status packets from USB flash device 46 when a new status pacis available. Using 
these status packets, USB flash device 46 can transmit, to host platform 44, the results 
of different commands issued by host platform 44 in its requests (not shown). For 

15 example, the read command status packet contains one of the available status words 
such as "success", "error" or "invalid address", which enables host platform 44 to 
determine the result of the read command (not shown). Similarly, the erase status 
packet contains a status word indicating the completion of the erase process. A write 
status packet is used by USB flash device 46 to notify host platform 44 about the 

20 result of the write command, for example whether the command was successfol or 
erroneous, and whether USB flash device 46 is ready for additional write requests 
from host platform 44. 

A Memory Technology Driver, or MTD 78 typically contains routines to read, 
write and erase the flash memory device controlled by the controller operating MTD 

25 78. In addition, MTD 78 optionally contains an identification routine for recognizing 
the proper type of flash memory device for which MTD 78 was designed, so that the 
controller can determine which MTD should be activated upon interacting.with a 
particular flash memory device array. In addition, an identification routine should be 
able to detect the size of the array of flash memory devices, including the number of 

30 flash memory devices within the array, and various features of the flash array 
geometry, such as interieaving and bus width. This information later enables host 
platform 44 platform to determine the address space and size of the storage media. 
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U.S. Patent No. 5,799,168, previously incorporated by reference, discloses an example 
of such an MTD for a flash device. 

Using the above described protocol and architecture, host platform 44 can 
optionally implement any application which is implementable with any regular 
5 memory mapped or I/O mapped flash memory device. For example, host platfomi 44 
can give a standard block device interface to each application, such as a magnetic 
storage medium •'hard disk" drive, as disclosed in the previously described U.S. 
Patent No. 5,404,485. 

As an example of a preferred embodiment of the present invention, the 

10 operation of a host system connected to a USB flash device according to the present 
invention is described with regard to the processes of identifying, programming, 
reading and erasing the flash device. For the purposes of illustration only and without 
intending to be limiting in any way, the exemplary USB flash device has an array of 
two flash memory modules, each of which is 64Mbit in size. The address translation 

15 table is within the flash device so that host platfonn operates with logical addresses. 
All commands and return codes between the flash device and the host platform are 
carried on USB data packets, and are transferred through USB data pipes. The exact 
structure of the packets, pipes and timings are described in the USB specification. 
The operation of the exemplary device and system according to the present 

20 invention is as follows. When the USB flash device is first connected to the host 
platform, the USB host controller assigns an address to the USB flash device on the 
USB bus, and also assigns resources as described in the USB specification. The USB 
flash device actually asks the host platform to assign these resources, and must inform 
the host platform how much of these resources are needed. Thus, the USB flash disk 

25 can optionally support slower device speeds if the USB host platform has already 
allocated resources to other devices. 

The USB controller also negotiates with the flash modules and determines the 
size and manufacturing type of these modules. The controller then builds an 
identification structure holding this information, as well as the translation table and 

30 logical address space. 

After the USB host controller identifies the USB flash device, the host 
platform often uploads a USB client driver. The driver issues an identification request 



wo 00/60476 



PCT/USOO/07087 



13 

command to the USB host controller, causing the controller to transmit an 
identification data packet 80, shown in Figure 7. Identification packet 80 contains 
PE) field 22 and checksxmi field 26, as described previously for background art Figure 
2. Identification packet 80 also contains an "identify'* operation code in an operation 
5 code field 82. The packet extractor of the USB flash device receives identification 
data packet 80 and transfers the operating code of the "identify" command to the 
application command interpreter. 

In response to the "identify" command, the flash device then sends an 
identification data packet 84, shown in Figure 8, In addition to the fields shown in 

10 Figure 7, identification data packet 84 also contains information about the size of the 
flash device in a flash device size field 86, as well as information about the size of the 
minimal erase unit for erasing the flash memory in an erase unit size field 88. 

All of the packets described in this example are only data packets which are 
sent on the USB bus. Before each data packet is sent, a USB token packet is 

15 transmitted, instructing the USB controller as to the identity of the device end point to 
which the data packet should be transmitted. Upon successful reception of the packet, 
the USB controller issues a USB ACK packet as described in the USB specification. 

Once the device drivers in the host platfomi receive this status packet, the 
drivers can start issuing read and write commands to the USB flash device with the 

20 application commands. When a write request is sent, a USB data packet with the 
operation code for the *Nvrite" command, and the buffer containing the data, is 
transferred to the USB flash device. A write data packet 90 is shown in Figure 9, 
which again includes the fields shown previously in Figure 8, except that write data 
packet 90 also includes a write field 92 with the 'Vrite" operational code; an ADDR 

25 field 94 with the logical address to be written; a LEN field 96 with the length to be 
written; and a DATA field 98 which contains the actual data to write. The packet 
extractor extracts the operational code from write data packet 90 and transfers this 
code to the application command interpreter. The logical address is transferred to the 
address resolve module which translates this logical address to a physical address on 

30 one of the flash modules. The data handler optionally calculates error correction and 
detection mechanisms if employed by the USB flash device. Once all of the flash 
memory modules are ready, a "write" command is sent to the flash module or modules 
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containing the physical address, which may optionally span across more than one , 
flash module to the MTD block. The MTD block then issues a 'Syrite" command on 
the data/address bus which connects the flash modules to the USB device controller. 
Once the operation is complete and a status packet is returned to the MTD, the result 
5 of the operation is transmitted to the host controller and passed to the device driver in 
the host platform. 

When the flash controller finishes the writing process, the controller signals to 
the host platfomi that the status of the USB flash memory device has changed, by 
sending a '*write status" packet 100, as shown in Figure 10. In place of data field 98, 

10 write status packet 100 contains a status field 102. The host platform reads the status 
packets fi-om the flash memory device, and fi-om write status packet 100, the host 
platform retrieves infomiation on the completion status of the write command by 
reading status field 102. In this example, the flash memory device repeats ADDR field 
94 and LEN field 96 in order for the host platform to have a reference to the specific 

15 conmiand related to status packet 100. 

As shown in Figure 1 1, a "read request" packet 104 contains the operation 
code for the "read" command in a read field 106, and the logical address of the desired 
location fi-om which the flash controller should read in an ADDR field 108. Upon 
receiving this command, the flash controller issues a read command to the MTD 

20 block, after the address resolve module has translated the address contained in ADDR 
field 108 toa specific physical address in one of the flash components. 

When the flash controller receives the data from the flash device, either after 
the read command was issued, or if an error occurred, the flash controller sends a 
signal to the host platform to indicate that a new status packet must be read. The host 

25 platform issues a read request and receives a "read status" packet 1 1 0 as shown in 
Figure 12. Read status packet 110 contains the address of the read data in ADDR 
field 108, as well as the length of the read data in a LEN field 112 and the data itself 
in a data field 114. Read status packet 110 also features the status word, according to 
which the operation was completed, in a status field 116. The read operation can be 

30 completed with many different status situations such as success, fail, error detected, 
invalid address, invalid length and so forth. 

When the host platform needs to erase an erase unit in the flash device, the 
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host platform issues an "erase request" packet 118, shown in Figure 13. This packet 
contains the "erase" operation code in an erase field 120, and the logical address of the 
erase unit in an ADDR field 122. Upon receiving such a request, the flash controller 
translates the logical address to a physical erase unit address on one of the physical 

5 address spaces of the flash modules, and issues an erase command to the MTD block. 
The erase process generally takes more time then a read or write process. 
When this erase process is finished, the controller notifies the host platform a new 
status packet is ready to transmit. The controller then transmits an "erase status" 
packet 124, as shown in Figure 14. Erase status packet 124 contains the address of the 

1 0 erased unit in ADDR field 122, thereby providing the host platfoim with a reference 
. to the erase requests. The status according to which the operation was completed is 
provided in a status field 126. 

It will be appreciated that the above descriptions are intended only to serve as 
15 examples, and that many other embodiments are possible within the spirit and the 
scope of the present invention. 
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WHAT IS CLAIMED IS: 

1 . A USB flash memory device for comiecting to a USB-defined bus, the 
flash memory device comprising: 

(a) at least one flash memory module for storing data; 

(b) a USB connector for connecting to the USB-defmed bus and for 
sending packets on, and for receiving packets from, the USB-defined 
bus; and 

(c) a USB controller for controlling said at least one flash memory module 
and for controllmg said USB connector according .to at least one packet 
received from the USB-defmed bus, such that data is written to and 
read from said at least one flash memory module. 

2. The flash memory device of claim 1, further comprising: 

(d) an electrical interface for connecting to said USB connector and for 
receiving said packets from said USB cormector as a plurality of 
electrical signals; and 

(e) a logical interface for connecting to said electrical interface and for 
translating said plurality of electrical signals to logic signals, said logic 
signals being passed to said at least one flash memory module. 

3 . The flash memory device of claim 2, further comprising: 

(f) a functional interface for receiving said logic signals such that if said 
logic signals represent a USB functional packet, said functiorial 
interface sends a USB command to said USB controller according to 
said USB functional packet. 

4. The flash memory device of claim 3, further comprising: 

(g) an application packet extractor for connecting to said logical interface 
and for receiving said logic signals, said application packet extractor 
extracting at least one packet from said logic signals; and 

(h) an application command interpreter for receiving said at least one 
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packet and for detennining a command according to said at least one 
packet, said command being passed to said USB controller. 

5. The flash memory device of claim 4, further comprising: 

(i) an address resolver module for receiving said at least one packet and 
for resolving an address contained in said at least one packet, said 
address being sent to said USB controller, such that said command is 
performed according to said address. 

6. The flash memory device of claim 5, wherein said command is a write 
. command for writing data to said at least one flash memory module and said address 

is a logical address for writing said data, such that said address resolver module 
resolves said logical address to a physical address of said at least one flash memory 
module. 

7. The flash memory device of claim 5, wherein said command is a read 
command for reading data frbm said at least one flash memory module and said 
address is a logical address for reading said data, such that said address resolver 
module resolves said logical address to a physical address of said at least one flash 
memory module. 



8. The flash memory device of claim 5, further comprising: 

(j) a data handler for performing an error detection and correction routine 
for said at least one flash memory module. 

9. The flash memory device of claim 8, further comprising: 

(k) a status handler for receiving said USB functional packet from said 

functional interface, and for sending a status packet concemmg a status 
of said at least one flash memory module according to said USB 
functional packet. 



10. 



The flash memory device of claim 9, further comprising: 
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(1) a MTD (memory technology driver) for receiving a write command and 
a physical address of said at least one flash memory module, and for 
performing said write command to said physical address. 

11. A USB flash system , the system featuring a USB-defined bus, the 
system comprising: 

(a) a flash memory device, comprising: 

(i) at least one flash memory module for storing data; 

(ii) a USB flash device connector for connecting to the USB- 
defined bus and for sending packets on, and for receiving 
packets from, the USB-defmed bus; and 

(iii) a USB flash device controller for controlling said at least one 
flash memory module and for controlling said USB connector 
according to at least one packet received from the USB-defmed 
bus, such that data is written to and read from said at least one 
flash memory module; and 

(b) a host platform for communicating with said flash memory device 
through the USB-defined bus, said host platform comprising: 

(i) a USB host controller for controlling said host platform; and 

(ii) a USB host connector for connecting to the USB-defined bus. 
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Figure I - Background Art USB Token Packet Structure 
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Figure 2 - Background Art USB Data Packet Structure / 
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Figure 3 - Background Art USB Handshake Packet 
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Figure 4 - Functional Bloclcs of a Background Art USB 
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Fig 7 - Flash Identification Request Packet 
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Fig 8 - Flash fldentification Replay Packet 
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Fig 9 -Write Request Packet 
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Fig 10 - Write Status Packet 
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Fig 11 - Read Request Packet 
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Fig 12 - Read Status Packet 
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Fig 13 -Erase Request Packet 
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Fig 14 -Erase Status Packet 
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